home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / iso9660 / mail / pine / imap.arc / text0008.txt < prev    next >
Encoding:
Text File  |  1993-07-02  |  3.8 KB  |  75 lines
  1. On Tue, 01 Sep 92 22:16:45 BST, A Grant wrote:
  2. > why not return percentage of quota used so far
  3.  
  4. The question is, what does that mean to the user?  Telling me that I am using
  5. 45% of my quota tells me nothing about the question of whether or not copying
  6. this 50,000 character will will blow me away or not.  Note too that other than
  7. remote COPY, there is very little that can be done in IMAP to *use* more
  8. quota.  You can reduce your usage via IMAP, but I question whether telling
  9. someone `you are using 95% of your quota' is going to do anything to encourage
  10. him to use less.  Remember, that statement can be interpreted to mean `you are
  11. only using 95% of what you are entitled to.'
  12.  
  13. I think this needs more consideration and input from other individuals.  I'm
  14. not sure if this is an IMAP issue or not.
  15.  
  16. > > Modern-day c-client does detect and clean up properly when quota problems
  17. > > hit.
  18. > Er, how? Do you mean the c-client in the Washington distribution has
  19. > agreed a private protocol (e.g. a text in a BAD message) to pass this
  20. > information on?
  21.  
  22. The /usr/spool/mail operations that could make the mail file larger are
  23. checked for a worst case expansion vs. quota and are rejected if it would run
  24. out of disk space.  If a quota problem hits with COPY, the COPY is completely
  25. backed out of and the entire COPY command is rejected with a NO.  Remember,
  26. the server does not run with privileges and so has to obey the kernel on
  27. quotas.
  28.  
  29. > I mean sending on a mail message at the server (i.e. in a mailbox) without
  30. > having it delivered to the client and then sent back via SMTP. Apart from
  31. > being more efficient, if the user gets a MIME message that breaks their
  32. > client (e.g. by being humungously large), server-end forwarding might be
  33. > the only means of passing the message on to the system administrator.
  34. > Ideally it should accept an attached note, and encapsulate the original
  35. > mail using MIME. But then you're half way to a 'send mail' function.
  36.  
  37. Most of us consider `mail forwarding' to mean encapsulating the message within
  38. another message.  You would be putting user interface and sending within a
  39. message.  `Remailing' in this fashion may be reasonable though.
  40.  
  41. However, this is merely `for efficiency' since the same resulting function can
  42. be accomplished by existing mechanisms.  This is a good reason to reject it;
  43. any function which by its fundamental nature is optional and exists only for
  44. `efficiency' tends not to get implemented widely.  You can either end up with
  45. a lot of protocol baggage or recognize reality.  Most modern protocol design
  46. does the latter.
  47.  
  48. > I guess 'draft message handling' would be more accurate. I wouldn't
  49. > particularly mind if a client had to extract draft messages out of the
  50. > IMAP2 server and then post them off using SMTP. What I am trying to get
  51. > out of is a situation where a user is tied to one system because all
  52. > their drafts are stored there. Our users want to treat mail like a
  53. > telephone network - walk up to the nearest PC or Mac and there you are,
  54. > complete with draft messages, user preferences etc.
  55.  
  56. Remote storage of mail drafts is an interesting suggestion and it is certainly
  57. something to bring up to the IETF-REMMAIL group.  I would support an effort on
  58. this, but I don't think it belongs in IMAP under the `avoid too much baggage
  59. in IMAP' banner.
  60.  
  61. Also, I'm not convinced drafts belong on the IMAP server as opposed to the
  62. `home directory' server.  What if the IMAP server is overseas (this is a real
  63. world situation for me!)?  Putting it in IMAP seems to be false `efficiency'.
  64.  
  65.  
  66. I think you have some really good ideas, just that you're seeking the wrong
  67. place to see them implemented.  The stuff you suggest belongs in a distributed
  68. mail system just as IMAP does, but it does not (necessarily) belong in IMAP.
  69. Please consider bringing it up to the IETF-REMMAIL group.
  70.  
  71. Regards,
  72.  
  73. -- Mark --
  74.  
  75.